One aspect of computer software is that it must be periodically updated with revisions, additions and/or deletions in order to continue to provide adequate functionality to the user, to optimize the software and to correct errors and discrepancies that arise throughout the life of the software. As new features are added to software, it is desirable to replace the old software with the new versions as early as possible in order to provide the user with the features of the new software.
In certain types of computing systems, such as stand-alone or batch processing systems, changing software from one version to another presents few obstacles. Typically, the computer system is merely shut down during a period of day when there is little activity and the maintenance personnel are readily available. The old software is then simply removed and replaced by the newer version of the software. Thereafter, the computing system is restarted and all future data processing is done with the new version of the software. This procedure, of course, assumes that the new software has been adequately tested and debugged on an off-line system to the point that the software personnel and the operational management are confident that it will adequately perform the functions for which it is intended without undue interruptions that require halting and then re-starting the entire computing system.
In other types of computing systems, such as modern stored program control (SPC) telecommunications exchange systems (commonly referred to in the industry simply as "switches"), neither the testing of new versions of software nor the changing of software in the system is as easy as in stand-alone or batch processing systems. For example, new versions of software cannot be effectively tested without being placed into actual operation processing calls. The software must be tested while in operation in order to determine whether the software will adequately function under live operating conditions and whether the new portions will properly interface with all of the other software blocks that form a part of an operational SPC switching system. In addition, telecommunications switching systems are virtually never out of operation. Ideally; these systems would run perpetually, without interruption because of the continuous need for communications services within a community. That is, there is a continuous flow of telecommunications traffic being processed through the system even at off hours of the day or night and any interruption in the operation of the switch results in a non desired disruption of the telecommunications traffic. Such a disruption could be extremely damaging to the system's operation and its effectiveness, as well as its acceptance among users or costumers of the system.
These real-time requirements of telecommunications exchange systems place severe constraints on both the testing of enhanced versions of the software, or portions thereof, containing new or improved functionality, as well as the substitution of software containing error corrections or "bug fixes" in the switch without disrupting existing telecommunications traffic being processed by the switch. Therefore, integrating new versions of software components or units into the system using the traditional "edit-compile-link-load-run" approach is not desirable.
Another problem associated with the replacement of software in a operating computer system, such as telecommunications switches, is the state transfer between processes within the old software to processes within the new software, and especially the synchronization thereof. A process uses or comprises resource objects, which are object types that handle information on a hardware resource or an internal data structure. In context of the present invention it shall be understood that state transfer is the transfer of the state of a resource object. The state for a resource object is characterized by being allocated or deallocated. The state transfer between processes within the old software to the new software is essential to the users or customers of the system, since the state of the resource objects can be used by and survive several transactions. The states of the processes change over time, which makes it impossible to in advance incorporate the states of these processes into the new version of software, and thus if it is going to survive it has to be transferred from the old to the new software during the replacement thereof. What is preferred is a method that provides the capability to modify or extend the software together with the state transfer between the old and the new version of software while the system is in operation, and without any need for downtime.
Attempts have been made to solve the problems associated with incorporating new software into operating computer systems. For example, some advanced on-line operational systems in use today that do not operate in stand-alone or batch fashion will solve the problem of replacing old software in a manner that clearly differs from the method used with stand-alone or batch systems. However, such systems still replace software manually, although more transparently than in stand-alone systems, by requiring that individual users or user groups actively select whether or not to process using the new or revised version of software. This option may be exercised by users by modifying the concatenation of software to be utilized by processes operating under their individual user-id. The option remains available to users during a fixed period of time, usually measured in weeks or months, in which time the software migrates up several levels in the concatenation structure after successfully operating at each prior level without any discrepancies. Upon reaching the top level of the concatenation, the software is declared "operational" and the older versions are no longer available to users of the system. Insertion of new software into the system, as well as its migration up the various levels, is controlled by a process of configuration management, a manual process of reporting, approval, tracking software versions at each level and implementing approved changes.
As with the methods used to update software on batch or stand-alone systems, there are well known drawbacks to incorporating new or modified software into a system in this fashion. It is largely a manual, labour intensive system that is complex and time consuming. It leaves the control over whether and in what cases the system will operate with certain new software to the users with no means of performing gradual, restricted, on-line use so that errors do not proliferate or immediately affect all ongoing operations. The method of controlling access to new or revised software is directly linked and limited to the individual user executing the software.
Further, this method does not provide any means for transferring states from the old to the new version of software. Thus, the state transfer from the old to the new software is lost, which of course could affect the users in a negative way.
Other attempts to solve at least some of the problems associated with updating software in operational computer systems have been made. For example, in U.S. application Ser. No. 07/907,294, to Telefonaktiebolaget L M Ericsson, there is disclosed a method for replacing software in an operating computer system. With this method it is possible to test and change software during actual operation of the telecommunications switch without disrupting ongoing telecommunications traffic through the system. This method, however, is not directed towards transferring states from the old to the new version of software. Even if this method recognizes the need for such a state transfer it does not describe any means for synchronizing the data transfer from the old to the new software.
Therefore, it would be highly useful within in the telecommunications industry to be able to test and change software, including state transfer of processes from the old to the new software, during actual operation of the telecommunications switch without disrupting ongoing traffic through the system. The present invention provides such a method.